Global status journaling in NVS

ABSTRACT

A method and system for updating status information in a persistent storage. The method comprises the steps of defining a table in persistent storage (NVS) for holding information about changes to the status information; and when that status information is changed, making an entry in the table to record the changed information. A task is initialized to update the information on the disk drive. This updating is done by (i) checking the table to determine if any changes have been recorded in the persistent storage, and (ii) if any changes have been recorded in the persistent storage, then copying the status information from the persistent storage to the disk drive.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention generally relates to methods and systems for updatingcontrol or configuration data in a persistent storage.

2. Prior Art

Many computer systems, such as many main frame computer systems, usedirect access storage devices (DASD) to store data. Indeed, because ofthe vast amount of data stored in these systems, many of these computersystems include a controller, separate from the main, or host, computer,to manage the DASD. These controllers, which themselves may include oneor more processing units, act in response to commands or instructionsfrom the host computer to control and configure the DASD and the datastored thereon. The information describing the status of the DASD isreferred to as global status (GS) information, and this information maychange over time, for example in response to commands or instructionsfrom the host computer. It is important that this global statusinformation be maintained across various error conditions, including theloss of power.

The Global Status information is organized by Logical Subsystem (LSS),with a separate Global Status area for each LSS. Each Global Status areacontains all the information for the LSS. Some of this data is relatedto the state of the each device, some is related to the Copy Services(CS) sessions that exist in the LSS, etc.

There is a copy of this entire structure maintained in local storage.Whenever any of this information changes, it must be updated in somenonvolatile location. In current implementations, this may beaccomplished by updating the local copy in memory and then writing theentire structure for the LSS to DASD. The operation that initiated thestatus change is not considered to be complete until this write iscomplete. Since writing to DASD requires a long time, this method causeslong delays in the completion of operations which require a GS update.When there are many updates for different devices in the same LSS, eachone writes the same Global Status structure and the operations areunnecessarily serialized, causing even longer delays in theircompletion. For example, if 100 FlashCopy establishes are done on 100volumes in the same LSS, the same global status track will be written100 times.

SUMMARY OF THE INVENTION

An object of this invention is to improve systems and methods forupdating global status information in DASD.

Another object of the invention is to temporarily write global statuschange information to a buffer in non-volatile storage and thenasynchronously write the global status information from the non-volatilestorage to disk drives.

These and other objectives are attained with a method and system forupdating status information in a persistent storage. The methodcomprises the steps of defining a table in persistent storage (NVS) forholding information about changes to the status information; and whenthat status information is changed, making an entry in the table torecord the changed information. A task is initialized to update theinformation on the disk drive. This updating is done by (i) checking thetable to determine if any changes have been recorded in the persistentstorage, and (ii) if any changes have been recorded in the persistentstorage, then copying the status information from the persistent storageto the disk drive.

Further benefits and advantages of the invention will become apparentfrom a consideration of the following detailed description, given withreference to the accompanying drawings, which specify and show preferredembodiments of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a computer system in which the presentinvention may be used.

FIG. 2 shows a journal table used in the preferred implementation of theinvention.

FIG. 3 is a flow chart illustrating a procedure for making entries intothe journal table of FIG. 2.

FIG. 4 is a flow chart showing how the journal entries may be used toupdate status information.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 shows a computer system 10 generally comprising a host computeror computer system 12, data storage devices 14, and storage control 16.Preferably, storage control 16 includes host adapters 20, disk adapters22, and first and second memory clusters 24 and 26. Memory cluster 24includes volatile memory area 24 a, non-volatile memory area 24 b andprocessor means 24 c. Similarly, memory cluster 26 includes volatilememory area 26 a, non-volatile memory area 26 b and processor means 26c. Plural memory clusters are provided in system 10, it may be noted, toprovide redundancy in the storage controller 16, and preferably thesememory clusters are connected to different power sources.

Many types of host computers or host computer systems may be used withthe present invention. For instance, the host computer may be a mainframe computer. The present invention can also be used, for example,with servers, work stations, and multiple computer systems. The WorldWide Web may also be used as host computer 12.

Similarly, many types of data storage devices 14 can be used in thepractice of this invention. The storage devices may be, or include, forexample, disk drives, optical disks, CDs, or other data storage devices.

Also, as will be understood by those of ordinary skill in the art, anysuitable types of adapters 20 and 22 may be used in controller 16. Theseadapters are used to insure that data and messages are in the properformat as they pass between host computer 12 and memory clusters 24 and26 and between these memory clusters and storage devices 14. Theseadapters may be used, if desired, to provide other services. Manysuitable adapters are well known in the art.

Processor means 24 c and 26 c are used to manage the memory clusters 24and 26. These processors may also be used to provide additional featuressuch as monitoring, repair, service, or status access. Any suitableprocessor means may be used to provide the necessary or desiredfunctions.

In the operation of system 10, controller 12 is used to control and toconfigure storage devices 14 and the data thereon. In this operation,these controllers 12 use information, referred to as global statusinformation, that describes the status and condition of the storagedevices. With the embodiment of the system 10 illustrated in FIG. 1, acopy of this global status information is kept in each memory clusterand a copy is also kept in the storage devices 14. Whenever a change ismade to this global status information, these copies need to be updated.

As mentioned above, in current systems, this may be accomplished byupdating the local copy in memory and then writing the entire structureto the secondary storage disks. The operation that initiated the statuschange is not considered to be complete until this write is complete.Since writing to secondary storage discs requires a long time, thismethod causes long delays in the completion of operations that requirean update. When there are many updates for different devices in the samespecific disc area, each one writes the same change information and theoperations are unnecessarily serialized, causing even longer delays intheir completion. For example, if 100 changes are done on 100 volumes inthe same specific disk area, the same change information will be written100 times.

The present invention utilizes the fact that writing to non-volatilestorage (NVS) is performed at electronic speeds and is much faster thanwriting to the physical drive. The amount of space available in the NVSis less than the total amount of global status information that must bemaintained, so it is not possible to maintain the entire global statuswith the NVS. Instead, the NVS is used to store only the data that isactually modified and this data is written to the secondary storage assoon as possible, so that the amount of NVS space used by the journal atany one time is minimized. This is accomplished by defining a GlobalStatus Journal Table within the NVS. Whenever a status update isrequired, an entry is made into this table describing the changed data,in addition to making the update in the local memory structure. As soonas the journal update is complete, the data are considered to behardened and the operation complete from the client's viewpoint A taskis then initiated to collect the updates for each LSS and write them tothe secondary storage disks. When the write to the secondary storagedisks has completed, the corresponding journal entries are removed fromthe NVS.

If, at the time of a global status update, there is no space availablein the journal to add a new entry, then preferably, the update iswritten directly to the secondary storage disks.

Preferably, as illustrated in FIG. 2, the journal table 70 is comprisedof a header 72 that describes the valid entries in the table, followedby an array 74 of journal entries.

The LSS field 76 identifies which global status track is being updated.The Data Descriptor field 80 describes which part of the global statustrack was modified, and this field may have multiple parts to fullydefine the field that has been updated. For example, if it is a devicestatus field being updated, the modifier will also contain the deviceaddress; if it is related to a particular session, then it will alsocontain the session id, and so forth. The Data field 82 contains theactual data to be stored in the location defined by the Data Descriptor.If a single operation updates multiple fields in the global statusstructure, then it will result in the creation of multiple journalentries.

With reference to FIG. 3, when a global status update is made, the headand tail pointers in the header area are inspected to determine, at step102, if there is space in the journal for a new entry. If space is notavailable, then at step 104 a task is initiated to write the updatedirectly to the secondary storage disks. (It is anticipated that thiswill happen rarely, if ever.) After step 104, the journal entries forthe updated Global Status Track are deleted at step 106. If, at step102, there is space in the journal, the tail pointer is used todetermine the next free entry and the data describing the change iswritten into the table at step 110; and at step 112, the appropriateupdate is made to the local memory structure. As represented by steps114 and 116, if there is currently no task actively writing globalstatus data to the secondary storage disks, then a task is initiated andits ID written into the Journal Header area. If there is already anactive task, then no further action is required.

With reference to FIG. 4, when the Write to DASD task runs, it will takenote of the first and last valid entries in the Journal. It will then,at step 122, build a list (in bitmap form) of all GS tracks (that is,LSS's) that have updates. As represented by steps 124 and 126, a taskwill be initiated to write the global status for each of the LSS's thathave modified data. The entire global status structure that resides inmemory is written to DASD. This structure contains the most currentversion of the data and thus includes all of the updates that are in thejournal. In this way, in addition to the benefit of having the DASDwrites performed asynchronous to the update operation, multiple updatescan be written with only one write operation. The writes for each LSSmay be performed either serially or in parallel. It should be notedthat, since the entire local copy of each global status track iswritten, the Data Descriptor and Data fields of the Journal entries arenot used for this operation.

When all of the DASD writes are complete, all Journal entries from thefirst and last valid entries (at the time that the DASD writes wereinitiated) are removed from the Journal at step 130. At step 132, thetask determines whether the journal is empty. On the one hand, if no newentries were added after the time that the Write to DASD task started,then the Journal is now empty and the Write task is complete. On theother hand, if additional updates were made, then the head pointer isset to the first newly created entry in the Journal, effectivelyremoving all entries that have been written to DASD. The Write to DASDtask then picks up all the new modifications and makes another cycle ofwriting status tracks to DASD.

Modifications to this method may be made to have separate journalstructures for each LSS (that is, for each global status track). The NVSarea may be partitioned to have a separate area of each LSS and to haveseparate, independent processes to write the global status for each LSS.

As long as no incidents occur which lose or corrupt the global statusinformation in the local memory area, there is no need to use the statusinformation that resides in the Journal or on DASD. However, if thelocal memory copy is lost, for example due to a power loss, then thismemory copy must be rebuilt, using the nonvolatile information that hasbeen saved. In the current implementation, that is, without theJournaling of updates, this is done by simply reading the global statusfrom DASD and using it to rebuild the status information in memory. Withthe above-described Journaling of the present invention, however, theDASD does not necessarily contain all of the updates because there maybe information in the NVS journal that has not been written to DASD. Asecond step in the recovery is required.

Specifically, when it is determined that the global status informationmust be rebuilt, the global status tracks are first read from DASD intothe local global status structures. Then, each Journal entry isprocessed, in order, and the update described by the Data Descriptor andData fields applied to the global status structure. After all updateshave been applied, then the state has been restored to the correctcondition.

While it is apparent that the invention herein disclosed is wellcalculated to fulfill the objects stated above, it will be appreciatedthat numerous modifications and embodiments may be devised by thoseskilled in the art, and it is intended that the appended claims coverall such modifications and embodiments as fall within the true spiritand scope of the present invention.

1. A method of updating status information in persistent storage, themethod comprising: defining a table in said persistent storage (NVS) forholding information about changes to the status information; when thestatus information is changed, making an entry in the table to recordthe changed information; maintaining a header for the table, the headerincluding pointers to the first and last entries in the table; andinitializing a task to update the status information on a disk drive,including i) checking the table to determine if any changes have beenrecorded in the persistent storage, and ii) if any changes have beenrecorded in the persistent storage, then copying the status informationfrom the persistent storage to the disk drive.
 2. A method according toclaim 1, further comprising the step of, after copying the statusinformation to the disk drive, removing the entry from the table.
 3. Amethod of updating status information in a persistent storage, themethod comprising: defining a table in said persistent storage (NVS) forholding information about changes to the status information; when thestatus information is changed, making an entry in the table to recordthe changed information; and initializing a task update the statusinformation on a disk drive, including i) checking the table todetermine if any changes have been recorded in the persistent storage,and ii) if any changes have been recorded in the persistent storage,then copying the status information from the persistent storage to thedisk drive; and wherein the table includes a header area and an array ofjournal entries, the header area includes pointers to the first and lastjournal entries, each of the journal entries identifying changedinformation.
 4. A system for updating status information in a persistentstorage, the system comprising: a persistent storage (NVS) defining atable for holding information about changes to the status information;and a controller to make an entry in the table when the statusinformation is changed to record the changed information; maintaining aheader for the table, the header including pointers to the first andlast entries in the table; and to initialize a task to update theinformation on the disk drive, by i) checking the table to determine ifany changes have been recorded in the persistent storage, and iii) ifany changes have been recorded in the persistent storage, then copyingthe status information from the persistent storage to the disk drive. 5.A system according to claim 4, wherein the controller, after copying thestatus information to the disk drive, removes the entry from the table.6. A system according to claim 4, wherein the controller uses thejournal entries to rebuild the status information in the volatilememory.
 7. A method of updating a copy in a disk storage of statusinformation in a memory area, the method comprising: defining a tablefor holding information about changes to the status information in thememory area; when the status information is changed, making an entry inthe table to indicate that the status information has changed;maintaining a header for the table, the header including pointers to thefirst and last entries in the table; and initializing a task to updatethe copy of the status information in the disk storage, including i)checking the table to determine if changes have been made to the statusinformation, and ii) if any changes have been made to the statusinformation, then updating the copy of the status information in thedisk storage to include said changes.
 8. A method according to claim 7,wherein the updating step includes the step of copying the statusinformation from the memory area into the disk storage to make a newcopy of the status information in the disk storage.
 9. A methodaccording to claim 7, wherein each of the table entries also includes arespective subset of information identifying a change to the statusinformation, and further comprising the step of using the subsets ofinformation in the table entries to rebuild the status information inthe memory area.
 10. A method according to claim 7, wherein the memoryarea includes a non-volatile memory area, and said table is maintainedin the non-volatile memory area.
 11. A system for updating a copy in adisk storage of status information, the system comprising: a memorystorage defining a table for holding information about changes to thestatus information; and a controller for making an entry in the table,when the status information is changed, to indicate that the statusinformation has changed, to maintain a header for the table, the headerincluding pointers to the first and last entries in the table; and toinitialize a task to update the copy of the status information in thedisk storage by (i) checking the table to determine if changes have beenmade to the status information, and (ii) if any changes have been madeto the status information, then updating the copy of the statusinformation in the disk storage to include said changes.
 12. A systemaccording to claim 11, wherein the controller updates the copy in thedisk storage by copying the status information from the memory area intothe disk storage to make a new copy of the status information in thedisk storage.
 13. A system according to claim 11, wherein each of thetable entries also includes a respective subset of informationrepresenting a change to the status information, and the controller usesthe subsets of information in the table entries to rebuild the statusinformation in the memory area.
 14. A system according to claim 11,wherein the memory area includes a non-volatile memory area, and saidtable is maintained in the non-volatile memory area.
 15. A programstorage device readable by machine, tangibly embodying a program ofinstructions executable by the machine to perform method steps forupdating a copy in a disk storage of status information in a memoryarea, said method steps comprising: defining a table for holdinginformation about changes to the status information in the memory area;when the status information is changed, making an entry in the table toindicate that the status information has changed; maintaining a headerfor the table, the header including pointers to the first and lastentries in the table; and initializing a task to update the copy of thestatus information in the disk storage, including i) checking the tableto determine if changes have been made to the status information; andii) if any changes have been made to the status information, thenupdating the copy of the status information in the disk storage toinclude said changes.
 16. A program storage device according to claim15, wherein the updating step includes the step of copying the statusinformation from the memory area into the disk storage to make a newcopy of the status information in the disk storage.
 17. A programstorage device according to claim 15, wherein each of the table entriesalso includes a respective subset of information identifying a change tothe status information, and said method steps further comprise the stepof using the subsets of information in the table entries to rebuild thestatus information in the memory area.
 18. A program storage deviceaccording to claim 15, wherein the memory area includes a non-volatilememory area, and said table is maintained in the non-volatile memoryarea.